Floppyshop 2/Floppyshop - 2.zip/Floppyshop - 2.iso/diskmags/0022-3.564/dmg-0055/597.txt

Text File | 1997-04-16 | 12KB | 272 lines

INFO-ATARI16 Digest         Thu,  2 Nov 89       Volume 89 : Issue 597

Today's Topics:
                          Am I a DA? (long)
         Congratulations (was: GEMDOS Extended Argument Spec)
                        GNU C and sizeof(int)
                         GNU C and SOZOBON C
                         LHARC Source wanted!
             Naive Question : ST & IBM Disk Compatibility
               Ramblings of a madman (Sozobon C topics)
----------------------------------------------------------------------

Date: 1 Nov 89 19:51:32 GMT
From: imagen!atari![e-mail]  (Ken Badertscher)
Subject: Am I a DA? (long)

Several people have asked me recently how to write a program so that
it could be used as both a desk accessory and as a program.  The problem
is not too hard, but requires some mucking about with the startup code
of the program - if you're not willing or able to do that, then you needn't
read any further...

Still with me?

Okay, the key to identifying whether your code is running as a DA or a
program is the parent basepage pointer in the basepage.  If the
longword in the basepage at offset 36 (0x24) - which points to the
basepage of whatever launched your code - is NULL (0), then your code
is running as a DA.  The problem is that a DA does not get a pointer to
its basepage on the stack like an application does.  In fact, a DA's
registers (including the stack pointer!) contain garbage on startup,
which is the reason that a DA must set up its own stack straight away.

The startup code provided with some compilers includes code which
checks whether the parent basepage pointer is null or not.  This code
usually gets around the aforementioned problem of locating the basepage
by taking advantage of the way the system normally loads DAs and
programs.  The TPA (Transient Program Area, i.e. text, data, BSS, and
stack/heap) of a program or DA is normally contiguous with its basepage
in memory.  All the startup code has to do is look back 256 bytes from
the start of the text segment, which is the first part of the TPA, and
voila!  There's the basepage.

The operative word here is "normally."  It is not entirely safe to
assume that your program's basepage is contiguous with its TPA, because
it is possible for a program to set up a non-contiguous basepage and TPA
by using the more arcane Pexec() modes.  If you must assume that the
basepage and TPA of your program are contiguous, then your startup code
should validate that the basepage it is using points to a contiguous
basepage and TPA.  If the basepage and TPA are contiguous, then the
longword located 256 bytes before the text segment will point to
itself, since the first longword of the basepage points to the base of
the TPA.  Ideally, you should even go a step further, and check the
text base address.  The third longword in that basepage should match
your startup code's base address.

There is an alternative method which is not used by any startup code of
which I am aware.  This method will allow the same code to run as a
program or as a DA, and will also allow it to run with a non-contiguous
basepage and TPA.  It also takes advantage of the way the system
"normally" does things, but we can guarantee that the system will always
do things this way.

I mentioned before that a DA's registers are garbage on startup, well,
that's not entirely true.  When the DA gets control, register A0 always
points to its basepage.  When a program is started by a GEMDOS Pexec(),
register A0 is always cleared.  Using this fact, it is possible to
implement startup code which gets the basepage address from register A0
if the code is launched as a DA, or at 4(sp) if the code is launched by
Pexec().  Since it knows how it was launched, it can also do the stack
setup required of a DA, otherwise it can use the stack pointer it gets.

I strongly recommend that startup code implementors use the latter
method of DA/program startup.  It allows far more flexibility in Pexec
implementations, it works just as well as the "text base minus 256"
method, and it is supported by Atari.


--
   |||   Ken Badertscher  (ames!atari!kbad)
   |||   Atari R&D System Software Engine
  / | \  #include <disclaimer>

------------------------------

Date: 2 Nov 89 19:30:11 GMT
From: ubc-cs!grads.cs.ubc.ca![e-mail]  (John Buchanan)
Subject: Congratulations (was: GEMDOS Extended Argument Spec)

In article <[e-mail]> [e-mail] (Ken Badertscher) writes:
>
>GEMDOS EXTENDED ARGUMENT (ARGV) SPECIFICATION
>
>Introduction


This is what we have being waiting for.  Nice to hear an OFFICIAL
word about this whole mess.


WELL DONE ATARI.

------------------------------

Date: 2 Nov 89 17:58:11 GMT
From: watmath![e-mail]  (Ray Butterworth)
Subject: GNU C and sizeof(int)

In article <[e-mail]> [e-mail] (Piet van Oostrum) writes:
>Dlibs and Gemfast have been written for a 16 bit compiler.
>I have a version of Dlibs that I adapted for use with GCC.
>It has been modified for 32 bit integers.

This reminds me of something I've been wondering about for a while.
Why does GCC on the ST have 32 bit ints?
Surely 16 is the obvious size considering it has 16 bit memory access.
(Note that I don't consider
 "so that badly written code will still work ok"
 as a valid reason.)

Every time anything accesses an int in CGG, it requires two memory
accesses.  Most programs are full of things like "++i" or "i+=7"
or "if(i>j)", and such things take approximately 100% longer when
ints are 32 bits.

Even worse, take a look at the source for functions that interface
with the OS.  Typically the function has a loop that takes the 32-bit
ints from the stack and moves them to 16-bit words and then invokes
the system trap with a pointer to this list.
Surely it would be many times faster with 16-bit ints,
since the function could simply pass a pointer to the stack arguments
without having to do any of the moves and resizing.

Has anyone made a 16-bit GCC and library and done a comparison?

------------------------------

Date: 31 Oct 89 17:09:53 GMT
From:
 gem.mps.ohio-state.edu!samsung!shadooby!mailrus!jarvis.csri.toronto.edu!utgpu!w
atmath!ria!uwovax![e-mail]
Subject: GNU C and SOZOBON C

In article <[e-mail]>, [e-mail] (pa1329) writes:
> 1.  Can the GNU C complier use dlib and gemfast bindings for writing
> TOS and GEM programs?
>

The new GCC library (distributed with versions 1.34 and later) is partly
based on dlibs, and partly on other PD routines. The intention was to
provide the maximum degree of portability with UNIX and MS-DOS
systems. I think it succeeds quite well; I've used the GCC to port dozens
of applications (including NetHack 3.0) with remarkably little effort.
There is a GEM library available for the GCC, which seems fairly complete;
I can't recall if it was based on gemfast or not. There's also a port
of Berkeley's curses package (you can't get much more portable than
that :-). All this stuff is available by anonymous FTP from
dsrgsun.ces.cwru.edu (129.22.16.2) and probably from other archive sites
as well. (Of course, source code is available for everything.)

DISCLAIMER: I'm biased; I helped put together the library, and wrote some
of the routines. What I didn't like, I fixed...

Eric Smith
[e-mail]

------------------------------

Date: 2 Nov 89 03:08:57 GMT
From: rochester!rit!ultb![e-mail]  (A.J. Yarusso)
Subject: LHARC Source wanted!

Help!
=====

  I am looking for the sources to LHARC, if they are in the public
domain...  LHARC is very slow and a bunch of us here in Rochester would
love to re-write.   Rest assured that this will be the first place an
improved version of LHARC would appear, so any help I receive in getting
the source will benefit you too (in the long run)....

  Thanks,

  (keeping my fingers crossed that LHARC is public domain)..

_____________________________________________________________________________
 Albert Yarusso, Rochester     [e-mail], [e-mail]
 Institute of Tech. _________________________________________________________
 Computer Science  /___   /    ?rutgers, ames?!rochester!ritcv!ajy2208
______________________/  /     [e-mail]     GEnie:  A.Yarusso

------------------------------

Date: 2 Nov 89 17:08:24 GMT
From: e2big.dec.com!ynotme![e-mail]  (Ray Wallace)
Subject: Naive Question : ST & IBM Disk Compatibility

In article <[e-mail]>,
 [e-mail] (John Ladasky;1021 Solano No. 2;528-8666) writes...
>but when I went to the PC on campus that is hooked in to the network, it
>wouldn't read it!

DCFROMAT will also make a ST floppy useable on a PC. Don't use folders on the
disk as this causes problems sometimes. If formatting on the ST doesn't work
try formatting it on the PC (format for DD not HD, ie: 726kb not 1.44mb or
whatever the exact # is) and then put it in the ST to copy the files onto.

I've had luck using DCFORMAT on the ST, writting the files on a Tandy PC, then
reading the files on the ST. Some combinations work for some people other
combinations for other people (or machines). The best you can do is try a few
different things and hope one way eventualy works for you.

Good luck,

---
Ray Wallace
                (INTERNET,UUCP) [e-mail]
                (UUCP)          ...!decwrl!oldtmr.enet!wallace
                (INTERNET)      [e-mail]
---

------------------------------

Date: 2 Nov 89 08:02:10 GMT
From: thelake![e-mail]  (Steve Yelvington)
Subject: Ramblings of a madman (Sozobon C topics)

In article <[e-mail]>,
     [e-mail] (Rat) writes ...

>Having just read a message in Vol. 89 Issue 565 questioning whether there is a
>shell available for Sozobon C, I would also like to second this question!
>
>I am starting my final year project using Sozobon C and would find a shell
>_VERY_ useful, espesially if it can handle environment variables.

Sozobon C works perfectly well with Un*x-style shells, such as Gulam, tsh,
etc. I use jShell, which perhaps John Stanley will someday quit making
perfect and post. :-)

But I suppose you're looking for a GEM shell for Sozobon C.

I worked on one for a month or two. A number of factors stopped me:

        * I'm not good enough at programming to make a "gee-whiz"
        graphic compiler shell -- something like Think C on the Macintosh.
        This is a hobby. I don't do this for a living.

        * I got involved in other projects, namely some Usenet netnews
        software.

        * I didn't find it useful.

The last point is probably the most important. I really didn't see much
use for GEM in the write-compile-link-test cycle. Working from a command
line is a lot more convenient. I'd rather type "cc fubar.c" than
point-click-point-click-point-click-point-click-knock-over-my-coffee-cup.

If you disagree, I'd like to hear why. What do you expect to get out of a
compiler shell? What sort of user interface do you envision? I might be
persuaded to dredge up my SeeShell code and start hacking at it again.

Or maybe you'll be inspired to write your own.

   -- Steve Yelvington, up at the lake in Minnesota
  ... pwcs.StPaul.GOV!stag!thelake!steve             (UUCP)

------------------------------

End of INFO-ATARI16 Digest V89 Issue #597
*****************************************
=========================================================================